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A method of updating firmware between 
an imaging device (10) and a host system (20) 
is disclosed. The host system detects that the 
firmware on the imaging device is incompatible 
with a configuration of the host system. In 
response, to detecting the incompatibility, an 
updated firmware image is transferred from the 
host system to the imaging device. 



20 



HOST APPLICATION SOFTWARE 60 


















OPERATING SYSTEM 40 



(2) 



CAMERA DRIVER 44 




PORT DRIVER 42 



PORT 26 



CAMERA 10 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


FI 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AV 


Australia 


GA 


Gabon 


LV 


Latvia 


SZ 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BG 


Bulgaria 


HU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


UZ 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


CI 


COte d'lvoire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






CU 


Cuba 


KZ 


Kazakstan 


RO 


Romania 






CZ 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






DE 


Germany 


U 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







WO 99/42924 



PCT/US99/01398 



AUTOMATIC UPDATE OF CAMERA FIRMWARE 

FIELD OF THE INVENTION : •' ~ ' ' = 

The present invention relates to the field of imaging. More particularly, 
this invention relates to updating firmware between an imaging device and a 
host system. ' ...... .1 

BACKGROUND OF THE Ti^VRNTT^TsI 1 : - ' ,/ . . 

Imaging devices, such as cameras, typically store still or moving (video)' ' 
image information on film, video tape, or other media. Digital cameras capture 
image information in digital format and store the image information in memory, 
such as a flash memory, or on other digital storage media. The digital image 
information can be downloaded to a host system, such as a personal computer. 
The image information can then be manipulated by rotating the image, cropping 
the image, or otherwise altering the image with software applications residing 
on the host system. 

The imaging device includes firmware that allows the imaging device to 
communicate with software on the host system. The firmware includes 
instructions for performing various functions. For example, the firmware may 
be used to determine the exposure of an image, sense color in a particular 
manner, compress image data, conserve power, perform self tests, and/or 
specify accessing and formatting protocols to the storage medium on the 
camera. 

Oftentimes, it is desirable to upgrade either the host software and/or the 
camera firmware with a new release of software or firmware. A common 
method for upgrading software is through the use of a patch, or service pack 
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upgrade. This method consists of distributing a set of programs via floppy disk, 
CD-ROM, or World Wide Web to the host machine. The service pack, when 
run, modifies the components of the host software that need updating. 

Updating the firmware is more problematic. This process is typically 
performed manually by a user. It may involve running an executable program, 
then resetting the imaging device. Manual updating of the firmware is 
inconvenient, and may lead to errors caused by incompatible versions of 
firmware and host system software. 
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SUMMARY OF THE PBRSBMT iwynnM , ■ , „ ... n . 

Ameftpd.ofupd^g.^^ pn an imaging,deyice coupled to a host 
system is disclosed. The host system detects that the firmware on the imaging , .. 
device is incompatible wi^acpnfiguration of me host system, In ; response to. 
^^#cJn^ W ^^ fW dat^ firmware image is transferred from the 
host system to the imaging device. In one embodiment, the updated firmware, .,. d: 
image i S; an older version of, firmware than,the one; that; is replaced,, ; 

from the accompanying drawings and from the detailed description that follows,, r.hv 
below .»..(•. 1 1 r 



WO 99/42924 



PCTAJS99/01398 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a representation of an imaging device that is attachable 
to a host system. 

Figure 2 shows one embodiment of the flow of information among the 
components of the host system when the imaging device 10 is first connected to 

the host system 20. 

Figure 3 shows one embodiment of the flow of information among the 
components of the host system after the host application software 60 has been 
initiated. 

Figure 4 shows one embodiment of the polling initialization process. 

Figure 5 shows an embodiment of the polling process between the 
camera API 62 and the host applications software 60. 

Figure 6 shows a flowchart of one embodiment of the process of 
checking whether a compatible imaging device is connected to the host system. 

Figure 7 shows a flowchart of one embodiment of updating the 
firmware. 

Figure 8 shows one embodiment of a state transition diagram of the 
firmware boot process. 

Figure 9 shows a diagram of an exemplary nonvolatile memory 400 
which stores the firmware. 

Figure 10 shows a flowchart of one embodiment of the process of 
initializing the host application software to establish a communication with a 
camera. 

Figure 1 1 shows a flowchart of one embodiment of the process of 
detecting that an imaging device such as a camera is attached to a host system. 
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DETAILED -D ESCRIPTION , ; . ..• ■■■■■■ ,. ; . 

A method of updating firmware between an imaging device and a host 
system is disclosed.- ,The firmware includes instructions which are used to 
control an embedded system, such as an imaging device. In one embodiment^ : 
the firmware update is performed automaticallyoipon connecting the imaging^ 
device to the host system,., This simplifies, operation for the. user while ensuring ■■>■■'■<> 
compatibility between the imaging device and the host software. • The firmware ^ • 
update may provide,r:bugV fixes, e^cements-.to;dgbrithms^pdat^ic6lbr:-' J r: ■ 
sensing, updated.compression, new protocols for accessing and formatting thfe*' "!<:••• 
storage medium, and soforth ?u As will become clear, the automatic firmware ! "i 
update is particularly useful, when multiple imaging devices with "different-' ' ; ■'■ 
versions, of firmware are used with !host systems . thathave different versions of ; 
software.!.! r >v .,,.-,-,•■} )y. hrslo ■■■< riao r.rrn' i,u >: :IA) .!c.x.; )u: 

The following descriptiotfdescfibestheJfirmware update in the context •»!.■"■ V/ 
of a system, that, transfers image information.between the image device and me :^ 
host system automatically upon coupling the image.device to the hostsystem:;n: 
However, the firmware, update is not limited.to such a system. • 

The imaging device may be an image capture device,. such as a camera.'- 
Alternatively, the techniques disclosed, can be used with any device that is I r 
capable of storing image information. -The host system may be any system : 
which is capable of manipulating image information. For example; .'the host ' • ■ 
system may be a personal computer such as an IBM-compatible persdhal ■ V. 
computer running on an Intel Pentium® or. Pentium® II processor. However, ■ . 
the host system could alternatively be a printer, plotter,-fax machine, display 
device, or storage device. . , ... ,- 
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For purposes of clarity, the following description is written in terms of 
the imaging capture device being a camera and the host system being a 
computer. It should be understood that other imaging devices and host systems 
may be employed. 

Figure 1 shows a representation of an imaging device 10 that is 
attachable to a host system 20. In one embodiment, the imaging device 10 is 
attached via a cable 22 to a port 26 of the host system 20. The imaging device 
1 0 is preferably coupled to the host system 20 using a data transfer protocol that 
supports a high data transfer rate. In one embodiment, the imaging device 10 is 
coupled to the host system 20 via a Universal Serial Bus (USB) connection. 
The USB connection provides for a data transfer rate of up to 12 Mb/s. Other 
connections and data transfer protocols may alternatively be used, such as the 
1 394 protocol. (More information on USB can be obtained from the World 
Wide Web at the URL http://www.usb.org/. The 1394 standard is maintained 
and distributed by the Institute of Electrical and Electronic Engineers. Firewire, 
one implementation of 1394, is defined by IEEE Standard 1394-1995.) 

Figures 2 and 3 are embodiments showing the relationship and 
messaging between components of the host system 20 and imaging device 
(camera) 10. Figure 2 shows one embodiment of the flow of information 
among the components of the host system when the imaging device 10 is first 
connected to the host system 20. The host system 20 includes an operating 
system (O/S) 40 and host application software 60. The host system 20 detects 
when an imaging device such as a camera 10 is attached to the host system 20. 
In one embodiment, the operating system 40 detects whether a camera 10 is 
attached to the system by polling the port 26. A port driver 42 may be used to 
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provide an interface between.the operating system 40 and the port 26. In c 

embodiment, the port 26 is a USB port and the port driver is a USB driver. 

The operating system may be one of a variety of different operating 1 
systems. « In. one embodiment, the operating system is a Windows* operating - 
system,.suchas'WjndoWs^95ior.Windows*i98-made by Microsoft ^ ;'-; : <:i 
Corporation. Windows, 98 -includes hooksrwhieh allow the pbllihg of ports- •= 
Other operating-systenis^may be mddffi^to.prdvide fdioSucli pfcllihg^The - v iqr, 
polling . is preferably performed in thecbackgrburid sO that- the. 'user heed not be -« •« :■ 
aware.that it i S| being performed. Alternatively; host applicationtsoftware 60 ' w:.:*.-. 
canperform ; thej,ollingof^^ , . > 

system;40,(instead : of by host application-software 60):has a performance - ,: 
advantage j S ince,% operating system is already set.^ •,, ,• 

activities, [S uch as keyboard pushes^ouse movements; ^ 
purposes of illustration,- the following description assumes that the bperating i. v 
system does the polling. A person skilled in the. art can make the modifications 
to allow an application to. db the polling/ 7 ' ,v ;oj..> :>ry.',:> mbwr, 

! When a camera. 1 0 is connected' toi the port 26 of the host system 20; the v 
port driver^ signals the operating system 40 that the camera has been attached . : 
to the host system 20, This is illustrated by the arrow marked (l) shown in ■• : ■ . 
Figure 1 . The operating system.40 identifiesthe device as a camera and loads 
the corresponding software driver 44 into memory: as illustrated by the arrow i . 
(2). In one.embodiment, the operating system 40,interrogates the camera 10 to 
get an identifier. The operating system 40 loads the software driver 44< < ,) -. 



* Third-party marks and brands are the property of their respective owners 
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corresponding to the identifier. In this example, a camera driver 44 is loaded by 
the operating system 40. 

The operating system 40 then loads one or more software applications 
corresponding to the camera. In one embodiment, the operating system allows 
software applications to be registered. Upon meeting a predetermined condition 
(such as a camera with a particular identifier being detected), the registered host 
application software is loaded. In this case, the host application software 60 
(for the camera) is loaded as shown by the arrow (3). In one embodiment, the 
camera driver 44 signals the operating system 40 to initiate the host application 
software 60. The host application software 60 initiates the transfer of image 
information between the image device (camera) 10 and the host system 20. The 
host application software 60 may also process images. For example, the host 
application software 60 can perform decompression and/or color correction on 
the images. Furthermore, the host application software 60 may perform 
rotation, cropping, and other image manipulation functions. 

Some operating systems, such as Windows 98 allow specific events to 
cause software applications to be launched. For example, the camera driver 44 
can be set up with registered events such as "connection detected with camera" 
or "shutter button on camera is pushed." Thus, an operating system can be set 
up to automatically launch an application such as the host application software 
60 when the camera 1 0 is attached. 

In one embodiment, if the camera driver 44 or the host application 
software 60 is not installed on the host system 20 when the camera 10 is 
attached to the host system 20, then the user is requested to provide the camera 
driver 44 and/or host application software 60 for the device that has been 
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attached tq%pqrt ; 26 i ,.Once i theinstallati 

proceedsas previously, described.,-. ; , . ,.- .. • j«j A . . r f, ;; . 

Fig 1 ""? 3 shqws one embodiment of the flow- of information airtong the 
components of.the host system after the host application" software 60 has been 
initiated., In-this embodiment v after being loaded, the host applicatidh-software 
60 creates and initializes a. camera Applications Programming interface (API) : ' 
62 as indicated.by, arrow. (4)v IT Thecaroera APJ:62.may perform- its task in a 
backgroundithread^ lathis manner,--the;host -application "software 60 heed riot' 1 
v^fcfor Jh^^e W .^I ^;.to CPmpleteHbeforeii>erfoiming-dther:|a^V 'Intfn* 
embodiment, ithe , camera, API .62 isla^OM object which lo^ds a 'dynamic' link ; - 
%^.(DLL;) 64 .as, shown, by c arrows (5)i TheDLL : may be O/W dependehi: ^ - 
The; camera APL62 communicatesj to the operating, system^©? Via! the DILL 64: • ? 
(In another embodiment, the camera API 62 incorporates the>DLL 64.) The •> '■' 
operating system 40/in turn communicates with; the' camera ?10 Jvia thecamera 
driycr..44iand-the.,pQ0 driver 42ias shown- by arrows (6);i,yi< '■ - who ,. w ,.vj 

Figurei4 J showsione; embodiment of the polling initialization process/ w«> 
The.polling initialization process begins with^me op'eratirig%stehi opening the . • 
host application software. The host application software '60 then creates and- 
initializes a camera API, 62;. In one embodiment; the host application software < 
60 addsitself to the. camera API's callback list, so that the host application ~ 
software 60 will be notified when the camera API is successful in the polling) I ■■■■ 
process. --i.,:., ,:'•..<• -. -.•:.,< i •■• i > J'Ux I ''''A/.'- M:}; 

In one embodiment, the camera API upon initialization resets itssiriterhal 
variables, loads a DLL, and creates and starts a background thread. The'camera 
API then inserts a message into the background threaded queue that tries-to ^ 
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open the camera driver. (A driver is "opened" by establishing a connection 
between the camera API and the driver.) In one embodiment, the camera driver 
is only opened when a camera is attached: If the camera driver cannot be 
opened, then a camera is not attached to the host system. If a camera driver can 
be opened, then a camera is attached. In one embodiment, the camera API 44 
attempts to open the camera driver every half a second. 

Figure 5 shows an embodiment of the polling process between the 
camera API 62 and the host application software 60. In this embodiment, the 
camera API 62 attempts to open the camera driver (CM_SIGNAL_STATUS). 
When it is successful at opening the camera driver, the camera API closes the 
camera driver, and notifies the applications in its callback queue. Since the host 
application software 60 is in the callback queue of the camera API, it is notified 
that a camera has been detected. - 

In this embodiment, the host application software 60 re-opens the 
camera driver 44 by signaling the camera API 62 to open the camera driver 44 
and check for a compatible camera (CMJ3PENJDRIVER). The host 
application software 60 can then send various commands to the camera 10 via 
the camera API 62 (and the operating system 40 and drivers 44 and 42). For 
example, the host application software 60 can request the number of images 
stored in the camera (CM_GET__NO_OF_IMAGES) . The host application 
software 60 can request a list of the names of the images and the image sizes 
(CM_GET_IMAGEJLIST), or it can request a particular image 
(CMJ3ETJMAGEJBY_NAME). 

In one embodiment, the camera API 62 checks whether a compatible 
imaging device is connected to the host system, and automatically updates the 

-10- 
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firmware on th^ jgiaging M?W;if necessary, -The automatic- fihnware.xipdate 
may be disabled or enabled as. afactory setting: by ^ manufacturer; or it may ; ,o 
be alterable, by the user. . 

. ! Fi 8^i0r? ho ^ A^^^ .... 

^Hfe* ?^^?^TO^e i ^^g.,^e^is SCWpw^d-tOLtherhost^ystein. ••• 
I ^i?.^.^Rdjment ) ,ftis,process is pe^nn^y-thejc^erajAPI.^As: ... . ..... 

previousjy ! memioned,,the ; c a mera API; 62 is created ^initialized by the host v.l- 
application software as, shown atblock. lOO^e camera APL62 loads.a/, n , , 

D hh&H.&®tte:W&$9& ?ystem.dependent at block 1.G2, and the host' 
applkatipnsoftware^qissues.a^ . 

104 i ^fflm^.fc!m9Pfo:mWte camera,driv.er 1 (52 i .yia the>DLL 64;-' : 
as shown in block 106. , 

Vs<'TU''n f.C' -.: '.•"!CV,';f. Mi V ' 

joy: d A f:te^lS^*?:^?!?» 4fM 2 issue Sj a}com^^ to 
fetch Ae camerajinterface^nym^ a unique. eamera fu , i „ . 

interface number is assigned to a set of commands ^hattfie,. camera supports, .. . 

Operation continues at decision ; block410.. ;> ^ 
the camera is compared with. an.interface table.iathe camera API 62. , Ifthe 
in *S£fe $W*&M 5r?t stored in the camera AI>I 62 interfacetable, then the ...... 

camera API 62 closes the camera driver and signals to. the ihost application : ; ... 
software that .the camera, is, incompatible, as shown atbloelcs: 1.12.and 114.. The i) 
W,^ 1 :! 8 ^^t^^Hntpate with .the icamera because the commands .-, 
that .the.camera.supports is not.known,,. , . 

nt^r? A^yP c H t ^Pr i ^e,inter^ce.number from.the.^amera is stored in;the': , 
interface table of the camera API 62, then the camera API 62 issues a command 
to the camera to fetch a hardware version number, as shown at block 120. 
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At block 130, the hardware version number from the camera is 
compared with a hardware table stored in the camera API 62. If the hardware 
version number from the camera is not stored in the hardware table of the 
camera API 62, then the camera API 62 is unable to check for an update. The 
camera API 62 signals the host application software that the camera is open for 
access, as shown at block 132. The camera API 62 is able to communicate with 
the camera because its interface is compatible, but it does not update the 
firmware because it does not recognize the hardware configuration. 

At block 130, if the hardware version number from the camera is stored 
in the hardware table of the camera API 62, then operation proceeds to block 
140. At block 140, the camera API issues a command to the camera to return 
the firmware version number. 

Operation proceeds to block 150. If the firmware version number is not 
different than that stored within the camera API 62, then the camera has 
updated firmware already. The camera API 62 signals the host application 
software that the camera is open for access. 

If the firmware version number is different than that stored in the 
camera API 62, then operation continues at block 160. If the manufacturer has 
disabled the firmware updates, then the camera API 62 does not perform a 
firmware update and signals the host application software that the camera is 
open for access. For example, the manufacturer may set a bit in a register of the 
camera disabling firmware updates. Although the installed firmware may not 
be the latest version, the installed firmware is still able to perform with the host 
software as long as the interface and hardware are compatible. 
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At block .170, a check is made whether theupdate has been tried before 
and failed. In one embodiment, a predetermined number of update tries is ' 
performed. If the update has been tried:before and failed, then the camera API 
62 signals to the host application software that the upgrade failed, and that the 
camera is open for access, !as shown at block 172: -u; - ■» ... 

■ , At block 1.70, if the update has not been tried before, then the flowchart 
proceeds. with' the firmware.update process,- as shown m Figiire-7. »"•■••■•; -«! 

.Figure^showsaflowchartofone embodiment of updating the " !1 ' 
firmware. At block 200, the camera API transfers an updated firmware -image 
to the camera. Inone embodiment, the camera API sends a download -firmware 
command to the.camera, ; sb that the firmware will be ready to receive a new ' 
firmwareimage. The updated, firmware image is then transferred from the host : 
system.to.the.camera,. In one embodiment the updated firmware image is ■ 
stored L on;the,camera in a temporary buffer^such as volatile memory/i 

At block 202, the camera API 62: closes the camera drivers This shuts 1 
down communication between the. camera and the host system: so that the 
firmware update is not interrupted. The camera API thensignals'the host 
applicationvsoftware:that it.is in the.process of updating the firmware, as shown 
at block 204. The cameraAPI begins to poll for the firmware to re-establish a 

connection With it. .;, /.c;. •) r./j:; >■„■■•< ■■ > 

The firmware is made up of a boot block and a code block! The boot 
block,- also called the.bootloader, is not replaced when the firmware is replaced. 
Only the code.block is replaced. The bootloader maintains the routineifor ■■>■■ 
updating the firmware. At. block 206, the bootloader validates that the updated 
firmware image is error free.. This can be performed by generating a checksum, 
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for example. The bootloader then substitutes the updated firmware image for 
the old (installed) firmware, as shown at block 208. In one embodiment, this is 
performed by transferring the firmware image from volatile memory into 
nonvolatile memory. The bootloader then either causes a reset, or it jumps to 
the start of the bootloader to initiate the newly updated firmware, as shown at 
block 210. This causes the bootloader to restart, at which point the bootloader 
checks for errors in the updated firmware, as shown at block 212. If the 
checksum is correct, then the firmware in the code block is executed, as shown 
at block 214 and 218. 

If the checksum is incorrect, the bootloader re-establishes a connection 
with the host system and moves to a waiting state, as shown at block 216. In 
this waiting state, the camera API may get status from the bootloader to 
determine whether the new firmware image was loaded properly into the code 
block, or whether there was a problem, and the bootloader is in the waiting 
state. The camera API may attempt another update of the firmware. 

Proceeding from block 218, once the firmware is able to restart with a 
correct checksum on its code block, then the firmware can establish a 
connection with the host system. The camera API will detect from its polling 
that the camera is connected at block 220. The camera API can then re-open 
the camera driver and perform accesses to the camera. 

Figure 8 shows one embodiment of a state transition diagram of the 
firmware boot process. The state transition diagram is divided into boot block 
states on the left hand side of the Figure 8 and a code block state on the right 
hand side of Figure 8. At state 300, a reset initializes the camera hardware. 
This may include resetting registers and/or turning off certain units of the 

-14- 
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camera, so that the camera is in a knownrstate. From state 300, there is a '< 
transition to state 302, at which the code block is checked. In'orie.embodiment, i 
a checksum is performed on the code block; If the checksum passes, then the 
instructions in the code block are executed, as shown at state 304. The ■ 
firmware in the code block is able to establish a connection with the host system 
and handles various. commands received from.the host system.: <If the firmware 
in the code block detects that the host system has issued a download command, 
then the ^.ti^goip-tarSffetoaO^,* which me -camera hardware is ;i f 
initialized into, a known.state. For example, the sensor and strobe may be ; < 
turned off, and; the; DRAM ; may-be turried on. In one embodiment,: the -camera • ' 
hardware is turned off when not in use in order, to save power. The state ■<>■■: • 
transitions to block 308, at which the updated firmware code is received from "'« 
the host system. The updatedfirmwarelcode .is temporarily, stored mDRAM in 
one embodiment, ij.. . .-, • , - : ,j <,,;;; i v y v . ...; f ;. , 

If there is a communication problem at state 308, then;there is a v!; ,U--r. 
transition to waiting state 3 1 0. At waiting state 3 1 0, the bobt'block waits for a 
command from the host system. 

From state 302, if the checksum fails, then there is also a transition to 
waiting state 310. At waiting state 310, the boot block waits for a command 
from the host system. The host system, for example, may request status 
information from the boot block. When the host system realizes that the boot 
block is in waiting state 310, the host system can issue another download 
command, which results in a transition back to state 308. < ■. -r, r 

From state 308, if the firmware image is downloaded without errors, . ; 
then there is a transition to state 320, at which the. code that was downloaded is 
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checked for errors. In one embodiment a checksum is performed. If the 
checksum fails, then the boot block returns to waiting state 310. If the 
checksum passes, then the state transitions to block 322, at which the code 
block is erased. Subsequently, the code block is re-programmed in state 324. 
From state 324, there is a transition back to state 300 at which the camera 
hardware is re-initialized and the state transition diagram restarts as previously 
described. 

Figure 9 shows a diagram of an exemplary nonvolatile memory 400. In 
one embodiment, the nonvolatile memory is a flash memory. In one 
embodiment, the boot block 402 and code block 404 are stored in the flash 
memory, and the boot block is locked so that it is not overwritten. The code 
block is re-programmable. 

In one embodiment, the nonvolatile memory also stores one or more 
imaging tables 406. The imaging tables may include information associated 
with the configuration of the camera. 

In one embodiment, the following imaging tables are stored in the flash 
memory. 

1) dead pixel table 

2) encoder table 

3) exposure table 

4) compander table 

5) color correction tables 

The imaging tables allow for processing of an image in the camera. For 
example, the dead pixel table may include information on particular pixels of 
the camera which do not work properly. The dead pixel table may be 
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determined during manufacturing testing, for example/ Alternatively, a'camera' ; 
may be able to determine dead pixels dynamically: The dead pixel table allows ' : 
for interpolation using neighboring pixels to compensate for the defective > -i". 
pixels, ,., ...,„.., ...... :! . ....... ........... -,. fr ,:. 

Similarly, ^e,QUjeriin»gingf tables ^lowmanipulation-of imaiihg-a£fe.«---- 
For example, :; the encoder table mayspecify particular values used ifbrieiidbding 
or compressing ^ image, H Exposure tables ^m^^^^ 

exposure time, : gain y! sU-pbe.use andiinterisiry, The companding stable may .no •> 
inclMde^o^^^t^pjda^^ a^t^resehtatitonlusing ifirfrft « 
number of b^te^p .a.bit.representatid^ 

conrection^les .may,!* us6dito.Qorrect^colors, ».r,.i\o<y. *U ;-.„<■.» ^no.mbrr.-nv. 
In one embodiment, the imaging tables include values thattetittuHt . ■ j.^ 
associated with a particular illuminant. For example, the imaging tables may 

..^l"? 6 .^ in eiflier : ••:•! T 

suirfight,^ttpresc^t,Jighimg, or tungsten^bulbjighting. 10l »„ noh , ,,, a 

I ... .p ......... . 

^g.™^M?Wp8 maybe stored into the nonvolatile memory 400 I 
dUrfng t ™fl^Y t may be u P dated later by thi firmware. In one . . •,. , { 

emb0d 5? 1 •'i^$ m ^ a f e ? ab,e 10 dele l e ima 8.mg:tables in the nonvolatile 
memory and transfer ( ne| imaging tables from the host system to the 

nonvo ^ m f: ro ^?.^ ^ e ^ '^e fi^e^ves commands from the .. , j 
hort^stowM^lndfcaW whether a table is to be fransfen^ed tolhe cameraf 
or whether an imaging table is to be deleted. 



j if:.: 



In one embodimaff/because'some nonvolatiie' memories (e.e some ; 

flash memories) are not able to botff read from the nbnvoh\uie~memo^ aid ' " ' 

■ '. -!:>. sat.:: ', .(.<>. i i • . ; : .'.• !•, i • 

wnte to the nonvolatile memory at the same time, a DRAM is used to " " ~~ " 
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temporarily store code from the nonvolatile memory. The firmware copies a 
portion of its code to the DRAM, then transfers execution to the DRAM. A 
microcontroller executing instructions out of the DRAM is able to then write 
the new imaging tables to the nonvolatile memory. Execution is subsequently 
transferred back to the code section of the nonvolatile memory. 

Tables 1 and 2 are used to show examples of how various versions of 
interfaces, firmware, and camera APIs on different cameras and personal 
computers (PCs) may interrelate. Table 1 indicates a configuration table stored 
in a first camera API (CAMAPI #400). Table 2 indicates a configuration table 
stored in a second camera API (CAMAPI #420). Some examples of various 
embodiments using the configuration information stored in these tables will 
help to illustrate. 



Table 1. 



Interface Identifier 


Hardware Version 


Firmware Version/ 
Firmware Image 


0x0101 


1.00 


1.00/Filename3 




1.01 


1.02/Filename4 




1.02 


1.07/Filename5 


0x0202 


2.00 


1.08/Filename6 


Table 2. 


Interface Identifier 


Hardware Version 


Firmware Version 


0x0303 


3.00 


1.09/Filename 8 




3.01 


1 .09/Filename 8 
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• 3.02-. .-!••■; t ■■■■■■■■■ ■ ■: 


'2.18/Filename 12 


0x0404 .... -.'.>,. 


4.00 ' ■ • 


'3.08/Fiienariie 13 '"' 



• Example i : Assume that two users, A ; and B, have the same version of 
host application software and firmware ^^rL^t^M^aiey^oti he 
1.0 which creates CAMAPI #400'havirig toe tabW of identifiers shown in Table 
1. The interface identifier is 0x010T,"and the ^ fir^wart vision is 1.00.' Next; ' 
user Areceivesah upgrade and updates Ws ( ho ! st applicant koftwa^e to version " 
1.02, which has the same interface' (OxOl'dl)'. ' U)l ! ; - 1 - >• > • 

After the host application software is upgraded, the first time that userA : 
tries to access the camera, the cahiera API 62 will detect an incdmpatibl^ 
version of firmware: It will V&*mmMitt0N£ autemaucklly, as 
was previously^described!' '-'Ki''-"-' 1 &-■■•.'<'•:;.<;.; >v ...i •■'.■muliyr-; </:-- ;;;: . 

Subsequently,; assume that user B ^ififl-hSb^^B h v^^ ! 1 .00 1 
on his camera) brings:his cam^ra to A's PC and r plugs it i'nl' The camera API on 
A's PC will again detect the firmware &id software ve&tfns. ThTcafeera f APi 1 
will update the firmware on B's camera to 1.02. B^s camera Wilf now have a v; ' : 
differentfirmware (1 .02) than me host software on B's PC. • When'B takes his 
camera back to B's PC, the camera API 62 will have no knowledge of the " 
firmware version 1.02. The camera API 62 will transfer the ? firmware image 
version 1.00 to B's camera. Thus, B*s camieraiis restdretfto its bnginal ' " : 
firmware so, that it can communicate with the software' on B's PC. ' - r ' * " 

The firmware update is transparent to B. B is "able to use his camera bh 
either A's updated system or B's system with older host application software. 
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Example 2: Assume that A has firmware version 1.00, interface 
0x01 01 , and B has firmware version 1.08, interface 0x0202. B cannot use A's 
PC unless A upgrades her software to recognize the new interface 0x0202. If 
B ! s PC uses the camera API including all revisions shown in Table 1, then B's 
PC can be. used with either A's camera or B ! s camera. 

Example 3: If user A has firmware version 1.0 and uses CAM API #400 
as shown in Table 1, and user B has firmware version 3.0 and uses CAM API 
#420, as shown in Table 2, then a PC must have both versions of software that 
interface with the separate interfaces to the cameras in order to access both 
cameras. 

In one embodiment, the interfaces have unique interface identifiers. 
One example of an interface is the TWAIN interface, which describes to an 
imaging application how to go about acquiring images from a scanner or other 
digital imaging devices. The current version of TWAIN is 1.7. TWAIN is 
maintained by a standards group made up of several industry participants. 
More information on TWAIN is available through http://www.twain.org. 
Proprietary interfaces may also be used. For example, DLLs supporting a 
particular application program so that the application program has the ability to 
transfer and delete images from the imaging device may be supported. 

The hardware identifier specifies hardware changes, for example, a 
stepper motor may be added to the imaging device. Firmware releases may be 
set up to track minor and major changes. For example, a minor change may be 
a bug fix or enhancement. A major change may be the addition of new 
hardware. 
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F *&P* \?<&P»S$ fl owchart of one embodiment of the process 6f-' : ' 
initializing the tost application software , to establish a communication with an 
imaging.device. Jn this disclosed embodiment, the imaging. device is a camera, 
■"^fe W; system is,a personal computer, n The flowchartibegins 1 at block 500. 
The prpcess continues at,block 502, atwhich , the tos t application software- 

s y st ?^ependent. a t>Jqck .... 

vi ■ ! M8Sfe^ft?»»K* . can 3 e F a totiayailable,. then the! flowchart returns to ' '■' 
block . 50,6, MP we ver, Jf a.camera.is .availa , 

51 -^,^*.^9<5k^l.O tn the,.c W era API, sends, a message to the host application >ii 
software indicating that a camera is available. Thelliost-applicatiori software 1 fJ»: ' 

™m?$<$p ^cmm^m^ PF*n.3t b!QckvS12 u3 T5he.c^m-era,API^H>onds 
by opemng.Ae ; camera.d^ 

driver, means, esteblishing a : connection : betwee^the camera APIrand .the camera m 

pomt. .: , .. x , VJJ j w ,_ rA fio ;.;^,-/-,j f ,, f;, 0 ,: Kit jiff.-fio -.-iiv-jv-. I' - :J 

i; •»,AXW.9P. k . 5 l l^iy the host application software requests that images are. ' • 

^^f^^om.^e C9mefc;tp theh,q^.sysjtem v The camera APLresponds.by, : 

♦^^TOj^^jnfP^P? fi»W,the.caineia to.,the,host application software .. 

^jHMMr. ^^?M?!^q%^4^u^eJ«^«^el l M.as well; as' ^ther.-.r 
information^ . 

orientation of the image, and so forth. The flowchartfterminates afcblpck 520. , 

. shows a.flqwchart pf one embodiment.of thcprocess off 

detecting that an imaging device such as a camera is attached^ aihostrsystem, • 
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The flowchart starts at block 600. It continues at block 602, in which the 
operating system determines if a camera is available. This may be done with 
the aid of a port driver such as a USB driver. If the camera is not available, the 
process returns to block 602. If a camera is available at block 604, the process 
continues at block 606 at which the operating system loads the camera driver. 

In one embodiment, an operating system such as Windows 98 is used by 
the host system. Windows 98 allows the driver to signal the operating system 
of the camera being connected to the host system (the connection event), as 
shown by block 608. The operating system then opens the applications that are 
registered with the connection event. In this case, the host application software 
for the camera is initiated, as shown at block 610. The flowchart then continues 
with the flowchart of Figure 10. 

If the operating system does not provide a way of opening an application 
based on the connection event, an alternate embodiment may use a "service" 
instead of the steps shown by blocks 608 and 610. The service is installed by 
the user iand is initiated on the host system automatically when the host system 
boots up. The service opens the host application software when a camera is 
detected. In one embodiment, the service uses the camera API to determine if 
the camera is available. Thus, the service acts as a mini-host application in a 
manner similar to that shown in Figure 10. However, the service initiates the 
host application software when a connection to the camera driver is established. 
The host application then establishes its own connection to the camera driver to 
transfer images from the camera. 

In one embodiment, the host application software 60 and the camera 
driver 44 are shipped with the camera 10. The host application software 60 and 
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camera driver 44 may be shipped via floppy disk or CD-ROM. Alternatively, 
the host application software 60 and camera driver 44 can be downloaded via 
the World Wide Web. The host application software 60 and camera driver 44 
are installed to a storage medium on the host system, such as a hard disk 
dynamic random access memory (DRAM), static random access memory 
(SRAM), or flash memory. , 

if> . J 1 } *e foregoing specifipation, the invention,has been described with 
reference to specific exemplary embodiments therepfiy It .vdlh- however be 
evident to someone having the benefit of this disclosure, that various 

?^?^?™™ d i-^?^j n ! ft: !f; be. made thereto^wiAoutdep^ingifrom the 
broader spirit and scope of the invention as set forth in the appended claims. 
The specification and 4rawings,are, accordingly, to.be jregardeddh an 
illustrative, rather than a ,re^ictiye : sense v >; :><U unhixwwiu 1 



■■i >v ho;: 



'/.•J . ilY.I:.. r.'-.Ti . . -jf.-" 
. , .-fir- 1 ; !' * % . ' ; :■ ••. ; 



■ : I 
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CLAIMS 

WHAT IS CLAIMED IS: 

1 . A method of updating firmware on an imaging device coupled to a host 
system, the method comprising the steps of: 

(a) detecting that the firmware on the imaging device is incompatible 
with a configuration of the host system; and 

(b) transferring an updated firmware image from the host system to 
the imaging device in response to the step (a). 

2. The method of claim 1, wherein the step (a) further comprises the steps 
of: 

(i) getting device interface information from the imaging device; and 

(ii) comparing the device interface information with interface 
information stored on the host system. 

3. The method of claim 1, wherein the step (a) is performed automatically 
upon establishing a connection between the imaging device and the host 
system. 

4. The method of claim 1, wherein the step (b) further comprises the steps 
of: 

(i) transferring the updated firmware image to a buffer memory; 

(ii) checking for errors in the buffer memory; and 

(iii) substituting the buffer memory for the incompatible firmware 
on the imaging device. 
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' ' 5 . The method of claim 1 , wherein the updated firmware image of the 
step (b) corresponds to an earlier version of firmWare than that detected on 
the imaging device in the step (a). 



6. The method of claim 1, wherein the step tbyifbrtlier comprises the step 
of: 

vwi , i> (i) loading one or more configuration tables into the imaging device 
: i . , from^thejhost system;: ■ .> ^ : tr. i; ■■: • ,i ; , . » 

> : 7. The methdd of claim '6, wherein' the one or more configuration tables 
are used to manipulate imaging "data oh the imaging* (device: ' 

8. A system comprising: 

• a processor; * * r ' :rn*:*v.;f« ::u<:- .-r. ■. " ■ *■ . 

a storage medium storing instructions which when ^xe'cuWd fcy the 
♦processor cause the processor 

(a) detecting that firmware pn an imaging device is out of date with 
a configuration of the system; and 

: (b) transferring an updated finpvyare image, from the system to the 
imaging device in response to the step (a). ' W r :|li .. r: . 

9. The system of claim 8, wherein the step (a) comprises the steps of: 

(i) getting device interface information from the imaging device; and 

(ii) comparing the device interface information with interface 

information stored on the system. 
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10. The system of claim 8, wherein the step (b) comprises the steps of: 

(i) loading one or more configuration tables into the imaging device 
from the system. 

1 1. The system of claim 10, wherein the one or more configuration tables 
are used to manipulate imaging data on the imaging device. 

12. A computer-readable medium having stored thereon a plurality of 
instructions which, when executed by a processor, cause the processor to 
perform the steps of: 

(a) detecting that firmware on an imaging device is incompatible 
with a configuration of a host system; and 

(b) updating the firmware automatically in response to the step (a). 

13. The computer-readable medium of claim 12, wherein step (a) further 
comprises the steps of: 

(i) getting device interface information from the imaging device; and 

(ii) comparing the device interface information with interface 

information stored on the host system. 

14. The computer-readable medium of claim 12, wherein the step (b) 

further comprises the step of: 

(i) loading one or more configuration tables into the imaging device 
from the host system. 
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15. The computer-readable medium of claim 14, wherein the one or more 
configuration tables are used to manipulate imaging data on the imaging 
device. 

16. A method of updating firmware on a camera, the method comprising 
the steps of: 

(a) connecting the camera to a host system, the host system set up 
with a configuration; 

(b) detecting that firmware on the camera is incompatible with the 
configuration of the host system; and 

(c) updating the firmware automatically in response to the step (b). 



. 17. The method of claim 16, wherein the step (b) further comprises the 
steps of: 



! 



(i) getting;device interface information from the camera; and 

• rUr]A«J . ... - — - 

(ii) comparing the device interface information with interface 
information stored on the host system. 



18. The method of claim 16, wherein the step (c) further comprises the ; • ■■? 
step of: 

(i) loading one or more configuration tables into the camera from the 
host system. 

19. The method of claim 1 8, wherein the one or more configuration tables 
are used to manipulate imaging data on the imaging device. 
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